
\chapter{Transformation d’un méta-modèle de graphes vers le méta-modèle de Dot}
\minitoc


\section{Objectifs}
Le travail à réaliser est à implémenter à l’aide du langage Kermeta.\\
Il consiste dans un premier temps à définir un méta-modèle des graphes orientés, puis, une fois ce
modèle fixé, nous devons le modifier à l’aide du mécanisme des aspects afin qu’il corresponde au
méta-modèle de Dot.\\
Enfin, nous devons définir quelques transformations pour démontrer la correction de notre code.

\subsection{Arborescence de l'exercice}
Les dossiers de l'exercice sont:
\begin{description}
\item[metamodel] contient les fichiers de description des meta-modèles
\item[model] contient les fichiers des modèles, chacun conforme à un méta-modèle
\item[transfos] contient les programmes de transformation de modèle
\end{description}

\section{Intégration du mécanisme des aspects}
Les aspects dans le langage Kermeta sont conceptuellement semblables aux différents types d’aspects
que nous avons précédemment étudiés : Ils permettent de rajouter du comportement ou de la structure
à du code déjà existant, sans modifier ce dernier.

Une fois leur syntaxe et leur intégration dans le code assimilées, nous nous sommes heurtés à un
problème sur leur utilisation : nous avons découvert qu’il était impossible à ces aspects de
modifier la structure ou le comportement d’un modèle existant. Ils ne permettent en effet que
d'ajouter des concepts à la structure et au comportement du modèle, alors que dans d'autres
langages les modifications sont possibles. Cela permet néanmoins de garder une certaines cohérence
dans le code, et l'assurance que le code fait n'est pas rendu inutile par un aspect\footnote{voir 
pour exemples les \href{http://en.wikipedia.org/wiki/Monkey_patch}{monkey patchs}}.\\
Si le modèle de base n’a pas été pensé dans cette optique et qu’il est en conséquent insuffisamment
expansible, nous ne pourrons pas le corriger ni l’adapter à l’aide du mécanisme des aspects. C’est
pour cette raison que nous avons dû songer à une refonte de notre méta-modèle initial, quand nous
avons voulu modifier son comportement.


\section{Conception du méta-modèle de graphes orientés}

La conception de ce méta-modèle a été refaite plusieurs fois, afin d'être suffisamment extensible
tout en n'incluant que ce qui nous a paru être le minimum, afin de ne pas surcharger le code. En 
effet, étant impossible de modifier le comportement de ce modèle dans un aspect, il fallait s'assurer
que le comportment spécifié était correct dans le méta-modèle de Dot.

Le fichier\texttt{OGMM.kmt} décrit ce méta modèle, qui se présente comme un arbre :\\

\subsection{Structure}
\begin{description}
\item[OGModel], le modèle de graphe orienté, définit des graphes, dont il est le père. C'est la
racine d'un modèle de graphe.
\item[Linkable] est l'interface commune aux éléments qui peuvent être reliés par un lien dans un
graphe. Les interfaces n'existants pas dans kermeta, elle est donc une classe abstraite. Par
facilité, elle permet de connaitre les graphes dans lesquelles elle est définie de manière directe
ou indirecte.
\item[Node] est une classe feuille de ce modèle : Il est décrit par un graphe, implémente Linkable.
\item[Link] est La classe représentant les liens d'un Linkable à un autre. Chaque Link est une
feuille de ce modèle, définie dans un graphe qui est donc son père.
\item[Graph] est un noeud dans ce modèle : défini par un modèle de graphe, ce qu'il est lui même, il
peut contenir des noeuds et des liens(Node et Link).
\end{description}

Chacune de ces classes a accès à la classe supérieur dans l'arbre : par exemple, un Linkable sait
quel graphe le définit. Ce mécanisme est déjà présent dans kermeta, mais nous avons préféré
l'ajouter de manière explicite afin que le code soit plus simple à comprendre.

\subsection{Contraintes supplémentaires}
Plusieurs contraintes n'ont pas pu être décrite dans la structure :

Un graphe du méta-modèle Dot peut être décrit par un autre graphe, formant ainsi une hiérarchie de
graphes. Il nous a alors paru indispensable de faire hériter la classe Graph de la classe
OGModel, uniformisant ainsi l'attribut \texttt{parent} du graphe pour qu'il soit un OGModel.\\
Cependant, dans le modèle Dot, un fichier décrivant un graphe ne décrit directement qu'un seul
graphe, tandis qu'un graphe peut en décrire plusieurs. Le fichier du graphe étant représenté par la
classe OGModel dans notre méta-modèle.\\
Nous avons donc décidé de placer un invariant, \texttt{OneGraph}, qui demande à ce qu'un modèle de
graphe ne comporte qu'un seul fils modèle. Étant donné qu'une classe fille hérite aussi des
invariants, nous avons fait appel à une fonction dans cette description d'invariant, nommée
\texttt{checkOneGraph()}, qui dans la classe OGModel teste si une instance ne possède qu'un seul
graphe fils, et dans la classe Graph est redéfinie pour que l'invariant soit toujours vrai.

Un lien (Link) du modèle ne devrait pouvoir lier, à notre avis, que des éléments dans sa portée,
c'est à dire des noeuds ou graphes visibles soit directement par le graphe qui le contient, soit par
des sous-graphes définit dans ce dernier.\\
Cette contrainte est définie par un invariant sur la classe Link, demandant à ce que le Linkable de
départ et celui d'arrivée soient tous deux visibles à partir du lien ; Ceci est fait en obtenant la
liste des Linkable du graphe conteneur, et en testant l'appartenance des deux éléments reliés à cet
ensemble.

Ces contraintes sont définies dans le (méta-)modèle, mais ne sont vérifiées qu'à la demande de
l'utilisateur, par exemple en appelant \texttt{checkAllInvariants()} sur un élément d'un modèle.
Nous avons cependant rajouté le test de la contrainte de visibilité dans une fonction utilitaire
d'ajout de lien dans un graphe, afin de voir précisemment à quel moment la contrainte est violée, 
mais surtout avec pour but de tester la levée d'exceptions dans kermeta.

\subsection{Nommage des éléments}
Afin de ne pas surcharger les fichiers de code, nous avons déplacé l'aspect "nommage" dans un fichier
d'aspect dédié, nommé \texttt{OGMMNaming.kmt}. Cet aspect spécifie que tout élément du modèle, hormis
la racine, doit avoir un nom, éventuellement vide.

Étant donné qu'il n'est pas possible de modifier les méthodes dans les aspects, et que nous avons
rajouté des données à la structure, nous avons opté pour le mécanisme de \textit{property} de
kermeta : la donnée utile est remplacée par une property, testant si une donnée accessoire vaut
void, la valeur par défaut dans kermeta, auquel cas elle la remplace par une chaine vide ; la
modification de cette property étant directement répercutée sur la donnée accessoire.

Cette modification structurelle a été définie dans une classe abstraite \texttt{NamedElement}, qui
dans l'aspect est héritée par la classe Linkable et Link, et par transitivité par les classes Node
et Graph.

De plus, une contrainte particulière a été ajoutée, qui est que dans un graphe, il ne doit y avoir
qu'un seul élément correspondant à un nom défini, hormis pour le nom vide.\\
Cette contrainte est en
fait ajoutée au modèle de graphe OGModel, et fait appel à une fonction redéfinie dans la classe
Graph. En effet, nous ne sommes pas sûrs qu'il faille absolument garder l'invariant d'unicité du
graphe défini par un OGModel, et faisant ainsi nous permettons de la désactiver facilement.


\section{Méta-modèle Dot}

Ce méta-modèle est défini, à partir du méta-modèle de graphe nommés, dans le fichier
\texttt{DotMM.kmt}, dans lequel il va simplement rajouter par aspect l'héritage des éléments
du graphe d'une classe abstraite \texttt{Parametrable}, laquelle contenant simplement une map de
texte sur du texte.

Encore une fois, nous avons utilisé le mécanisme de property de kermeta pour faire de l'
instanciation paresseuse, la map étant cette fois en lecture seule mais modifiable. Il eut été
intéressant de faire la liaison entre l'attribut ``name'' de la map et l'attribut ``name'' de la
classe NamedElement, mais nous ne voyons pas comment faire.

\subsection{Fonction utilitaires}
Nous avons de plus ajouté un aspect utilitaire, permettant de réaliser des opérations compliquées:
liste des noeuds accessibles et coaccessibles à partir d'un noeud, inversion des arretes d'un
graphe(demandé par l'exercice).\\
Cet aspect, uniquement comportemental, se base sur le méta-modèle de graphe simple (OGMM.kmt)
puisqu'il n'utilise que des fonctionnalités définies dans ce dernier. Il peut donc être utilisé
dans le modèle Dot.
